This is not the correct way to warn on an option. You'll want to use mkRemovedOptionModule as the rest of the codebase. Apply does work, but it's a really fragile way of doing this. Also applies to the vim.visuals.fidget-nvim.setupOpts.integration.nvim-tree.enable warning above.

unfortunately not possible due to mkPluginSetupOption, see #1305

sorry I lied xd, this throws a warning even if the option isn't set at all. We'll have to figure something out

from my understanding, we're relying on haskell-tools to start the lsp, so we should set this to false? (enable = true, which is the default, calls vim.lsp.enable("server_name")

enable is one of the fields not recognized by haskell-tools, as per :checkhealth:

Checking config ~
- ✅ OK No errors found in config.
- ⚠️ WARNING unrecognized configs in vim.g.haskell_tools: { "hls.enable", "hls.root_dir", "hls.filetypes" }

in that commect I left there, lsp_start_opts use some fields from hls_opts and hls_settings, which are the ones defined by us - there's no checks on enable

just tested this on this branch, there's no warnings without enable and the LSP still works properly

hmm in that case we should filter out enable before toLuaObject'ing it. I can do that in a separate PR, or you can do that in this one

do you mean adding that enable back, setting it to true so that it stays consistent with the rest, but filtering that enable when passed to toLuaObject?

enable = false should be kept, and enable should be filtered out before being passed to toLuaObject here. keep in mind that, the enable field is only used by nvf to call vim.lsp.enable('lspname'), and has no effect when passed to vim.lsp.config()

ok my bad, there was another effort in fixing this already #1191

I'll read through the discussions in that again later, I kinda forgot about it.

I think it's best to just leave haskell-tools alone for now, I'll merge in the other changes

repushed and removed the haskell commit